Efficient Visualization of Crash-Worthiness Simulations

Finite element post-processing has been dominated by software that is tightly integrated with simulation packages. Many of these packages have not kept up with the state-of-the-art developments in graphics technology and visualization techniques. Especially the large and time-dependent data sets resulting from crash-worthiness simulations in the automotive development process demand for new visualization tools which allow interactive manipulation of complex geometries and meaningful mapping of physical properties. This article demonstrates that careful design of scene graph structures and extensive use of texture mapping can improve rendering performance and visual appearance for post-processing tasks such as inspecting finite element discretization and analyzing intrusion depth or vector quantities. Furthermore, a new iconic visualization method is introduced which improves the understanding of crosssection forces and bending moments in longitudinal structures of the car body. Visualization in crash simulation One of the main goals in the development of a new car is the achievement of an optimal ”crash-worthiness” using as many analytical tools as possible and minimizing hardware-prototype testing. During the last few years, the absolute simulation time for modeling, computing and investigating a complete crash model has been reduced significantly. However, we notice a shift of the proportions between the time required for pre-processing, computation and post-processing respectively. The post-processing stage turned out to become the most time consuming activity performed by the simulation engineers. These changes and the rapid development of computer graphics technology during the last few years has increased the need for new visualization techniques to facilitate the analysis of crash-worthiness simulations. Considering the progress of scientific visualization in various areas during the last decade, it becomes obvious that the application of 3D visualization techniques to finite element analysis has not been a primary focus [4, 7, 12]. Nevertheless, the use of commercial visualization packages is now well established in the automotive industry. In the case of crash analysis, these traditionally employed post-processors have been designed to manage the enormous amount of simulation data on workstations with limited memory by performing animations of wire-frame meshes and polygonal representations of the simulated crash models. However, associated with these design criteria and with wide platform availability is a trade-off which leads to poor graphics performance in terms of available frame rates on high-end graphics subsystems. The deficit of many commercial post-processing tools in taking full advantage of the potential of modern graphics workstation was BMW AG, Entwicklung Karosserie, 80788 München, Germany, email: [email protected] Universität Erlangen, IMMD 9, Am Weichselgarten 9, 91058 Erlangen, Germany, email: [email protected] the starting point for a joint research between the computer graphics group of the University of Erlangen, Germany, and the BMW AG in Munich. This article describes some of the results which we achieved when applying state-of-the-art rendering techniques like scene graph design and extensive use of textures as well as iconic techniques from scientific visualization to time-dependent finite element data sets from structural mechanics. Effective scene graph design Several graphics APIs, such as IRIS Performer or OpenGL Optimizer, have been developed to take advantage of recent progress in compute server and workstation architecture with multiprocessing hardware in mind. Since those APIs are usually scene graph based, we can take advantage of model optimization during scene graph creation and benefit from multiprocessing using frustum culling and occlusion culling while traversing the scene graph to increase frame and interaction rates. Since the time-dependent databases of our FE models are very bulky, an efficient scene graph design is very important in order to handle the complex data interdependencies and to achieve high rendering speed. Our goal is to visualize meshes of about 250,000 finite elements with nearly the same number of nodes for each one of 60 time steps. Additionally, we have to represent the connectivity of the finite elements. Storing both coordinates and connectivity for each time step would be a waste of memory resources, since the element topology does not change during the crash. Therefore a much better approach is to use an indexed geometry. In OpenInventor, a widely used object-oriented 3D graphics toolkit, we can store the coordinates of each time step under a stateSwitch node and we can place the time-invariant description of the connectivity to the right side of that node once (see top of Figure 1). For each frame the scene graph is traversed by a render action object which holds the traversal state. One member of the traversal state is the actual set of coordinates which are defined by one of the coordinate nodes and which will be referenced by the indexedShape nodes. This approach appears to be a very memory efficient representation of our data in a scene graph structure, but it would not allow local scene graph optimizations or multiprocessing of independent subgraphs. This is because objects on the right hand side of the scene graph may depend on settings of the traversal state which have been made by scene graph nodes on the left hand side. Hence, we decided to use SGI’s Cosmo3D which forms the underlying 3D toolkit for OpenGL Optimizer, an API for large-model visualization supporting features such as multiprocessing, occlusion culling, and accelerated hardware-assisted scene manipulation. Cosmo3D provides a scene graph structure which resembles the semantics of the Virtual Reality Modeling Language [1]. It basically differs from that of the OpenInventor scene graph. There is no information inherited horizontally in the Cosmo3D scene graph which is traversed just downward from top to bottom in each branch. Thus, we have to choose a different scene graph structure (see bottom of Figure 1) which reduces redundant data storage as much as possible by taking advantage of indexed geometries and by shared instancing of scene graph nodes.